The present invention relates generally to software tools for use with transaction processing systems. More specifically, the present invention is a method and apparatus for using object linking and embedding (OLE) to access online transaction processing (OLTP) systems.
Online transaction processing (OLTP) systems are computer systems that are designed to provide controlled access to transaction protected resources, such as databases. In OLTP systems, a transaction protected resource may only be accessed or modified as part of a xe2x80x9ctransaction.xe2x80x9d A transaction is defined as a unit of work that has xe2x80x9cACIDxe2x80x9d properties. xe2x80x9cACIDxe2x80x9d properties means that a transaction is 1) xe2x80x9catomic,xe2x80x9d 2) xe2x80x9cconsistent,xe2x80x9d 3) xe2x80x9cisolated,xe2x80x9d and 4) xe2x80x9cdurable.xe2x80x9d To initiate a transaction, a client program performs a xe2x80x9cbegin transactionxe2x80x9d operation. Subsequently, the client program accesses and potentially modifies one or more protected resources. At the end of the transaction, the client program executes either a xe2x80x9ccommit transactionxe2x80x9d or an xe2x80x9cabort transactionxe2x80x9d operation.
Increasingly, OLTP systems are constructed using a client/server architecture where client programs, located on client computers, interact with server programs located on server computers. In this type of OLTP system, the server programs act as interfaces to transaction protected resources. Each server program is subdivided into one or more services. Each service is a portion of the server program that has been created to perform a specific type of transaction. For example, a service might be created to register new cars, or to move funds between bank accounts. Client programs access services by sending request messages to the appropriate server program. When required, a reply message is generated by the service and sent by the server program to the requesting client program.
In many client/server OLTP systems, the interaction between client and server programs is coordinated by a transaction processing monitor or TP monitor. TP monitors are programs that function as transaction middlemen between client programs and server programs. To access a protected resource, a client program sends a message to the TP monitor responsible for the protected resource. The TP monitor forwards the message to the appropriate server program. The TP monitor also forwards any result message generated by the server program to the requesting client program. Use of a TP monitor ensures that the xe2x80x9cACIDxe2x80x9d properties required by the transaction abstraction are maintained. Examples of TP monitors include Nonstop Tuxedo and Pathway/TS of Tandem Computers Inc., and CICS of IBM.
Personal computers are commonly used as client systems in OLTP systems. Typically, these computers use the Microsoft Windows(copyright) operating system. Windows(copyright) includes an object oriented method for program interaction known as object linking and embedding (OLE). Using OLE, programs may be configured to export object oriented interfaces to their internal methods. For example, a word processor may be configured to provide an object oriented interface to its spell checker. A program that exports this type of object oriented interface is known as an OLE server. Programs known as OLE clients use the object oriented interface provided by OLE servers to access the servers"" internal methods. Thus, an OLE client can use the spell checker of a word processor configured as an OLE server.
Much of the power of the OLE system stems from OLE""s widespread use. In effect, configuration of a program as an OLE server makes the program""s internal methods available to a wide range of existing OLE clients. Unfortunately, configuration of OLTP systems as OLE servers is problematic. This difficulty stems largely from the fact that the type of services provided by an OLTP system depend largely on the particular resource that the OLTP system is protecting. For example, the services included in an ATM network vary greatly from the services included in a payroll system. As a result, a different set of OLE objects may be required for each instance of an OLTP system. The unfortunate result is that it is more practical to provide OLTP systems without OLE interfaces than it is to build specialized OLE interfaces for each OLTP system. Thus, a need exists for a system that allows OLTP systems to be accessed from OLE clients.
The present invention includes a method and apparatus for providing OLE interfaces to OLTP systems. A preferred environment for the present invention includes an OLTP system having one or more server systems and one or more personal computers systems. The OLTP system includes one or more server programs that are responsible for one or more transaction protected resources. The OLTP system also includes a TP monitor that may be selected from a range of available TP monitors including Tuxedo, Pathway/TS and CICS TP monitors.
The server programs included in the OLTP system provide one or more xe2x80x9cservices.xe2x80x9d Each service is a function that the server programs performs for client programs. Typically, these services are tailored to reflect the transaction protected resources associated with the server programs. For example, server programs associated with employee databases typically provide services for accessing and changing individual employee records. In comparison, server programs used in ATM networks Atypically provide services for depositing and withdrawing money. Client programs access the services provided by the server programs by sending request messages to the TP monitor. The TP monitor forwards the request messages to the appropriate server programs and services. The server programs respond by sending reply messages to TP monitor. In turn, the TP monitor forwards the reply messages to the requesting client programs.
The present invention includes a visual OLE/TP development environment and an OLE/TP runtime environment. Using the OLE/TP development environment, the programmer defines one or more objects. Each object corresponds to one of the services provided by a server program. For example, a server program for an employee database would generally provide a service for accessing individual employee records. In this case, an employee object may be defined to correspond to the record access service. Each object may include one or more properties. Each object also includes methods, or procedures, that operate on they object. For each object, these methods include a begin transaction method, a commit transaction method and an abort transaction method.
Once the desired objects have been defined, the OLE/TP development environment creates an OLE type file containing OLE definitions for each created object. The objects defined in the OLE type file are part of an object hierarchy. At the top level of the object hierarchy, the OLE/TP development environment creates a special object known as an OLE/TP gateway object. Optionally, the OLE development environment may also create sample or skeleton code in a variety of languages such as C++ or Visual Basic. The sample code includes exemplary uses of each object defined.
The programmer then creates a client program that uses the objects that were defined in the OLE/TP development environment. This program may be created from scratch, or by modifying the sample code produced by the OLE/TP development environment. The client program may also be created as part of an existing application, such as a spreadsheet or desktop publishing application.
At runtime, the client program creates an instance of the OLE/TP gateway object. Creation of the OLE/TP gateway object initializes communications between the client program and the TP monitor. The client program then creates and manipulates one or more of the objects included in the OLE type library. For example, to access the database of employee records, the client program would create an employee object. The client program then uses the created object to perform transactions. More specifically, to perform a transaction, the client program calls a created object""s begin transaction method. Subsequently, the client program accesses and, in some cases modifies, one or more of the object""s properties. To complete the transaction, the client program calls the object""s commit transaction or abort transaction methods. In this way, the present invention provides an OLE interface to OLTP systems.
Advantages of the invention will be set forth, in part, in the description that follows and, in part, will be understood by those skilled in the art from the description or may be learned by practice of the invention. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims and equivalents.